Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move automations linkrel types to separate namespace #293

Merged
merged 3 commits into from
Nov 25, 2024
Merged

Conversation

vierbergenlars
Copy link
Member

The automation annotation endpoint should have their own namespace for link relation types.

For one, the automation annotations currently reuse the cg:entity linkrel to reference the entity collection. However, this causes a problem when fixing #291, because cg:entity is defined to be multi-valued; while this relation is single-valued.

Since we need a couple of separate link-relation type anyways, let’s reserve the automation CURIE prefix (and a separate URL namespace) to use for link relation types related to automations. This clearly separates the concepts from contentgrid data model concepts.

@vierbergenlars vierbergenlars requested a review from a team as a code owner November 22, 2024 13:43
@vierbergenlars vierbergenlars force-pushed the ACC-1742 branch 2 times, most recently from 0cb0f9a to 0579ba9 Compare November 22, 2024 14:31
@vierbergenlars
Copy link
Member Author

Since the second commit is just moving a bunch of files to a different package, you probably want to review this PR commit-by-commit.

@vierbergenlars vierbergenlars force-pushed the ACC-1742 branch 2 times, most recently from 1834c3a to 0d0de02 Compare November 22, 2024 15:00

@UtilityClass
public class AutomationLinkRelations {
static final String CURIE = "automation";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course a matter of taste, but this feels a bit long for me (considering we use cg: rather than contentgrid:). How about auto: or ext: for external?

@@ -14,5 +14,6 @@ public class AutomationLinkRelations {
public static final LinkRelation ANNOTATION = HalLinkRelation.curied(CURIE, "annotation");
public static final String ANNOTATION_STRING = CURIE+":annotation";
public static final LinkRelation TARGET_ENTITY = HalLinkRelation.curied(CURIE, "target-entity");
public static final LinkRelation REGISTRATIONS = HalLinkRelation.curied(CURIE, "registrations");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this just be automations:automations? Because it's not like you can register at that endpoint.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, those objects are the automations themselves, are they?
They are registrations for automations; containing automation annotations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's right that you cannot add registrations here, but you can list the registrations that already there.

@@ -14,5 +14,6 @@ public class AutomationLinkRelations {
public static final LinkRelation ANNOTATION = HalLinkRelation.curied(CURIE, "annotation");
public static final String ANNOTATION_STRING = CURIE+":annotation";
public static final LinkRelation TARGET_ENTITY = HalLinkRelation.curied(CURIE, "target-entity");
public static final LinkRelation REGISTRATIONS = HalLinkRelation.curied(CURIE, "registrations");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's right that you cannot add registrations here, but you can list the registrations that already there.

Create a separate namespace for automations, so the `cg:*` link
relations are not being reused in a different context at all.

Also move automations configuration to the module itself, and have the
autoconfiguration only perform imports.
This allows a cleaner extension and the possibility to test automations
separately from the rest.
The module is part of contentgrid-spring, so everything should stay in
that package namespace.
@vierbergenlars vierbergenlars merged commit 56861a7 into main Nov 25, 2024
9 checks passed
@vierbergenlars vierbergenlars deleted the ACC-1742 branch November 25, 2024 10:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants